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Abstract 

This paper describes our experience using parameterized al- 
gebraic specifications to model properties of software archi- 
tectures. The goal is to model the decomposition of re- 
quirements independent of the style used to implement the 
architecture. We begin by providing an overview of the role 
of architecture specification in software development. We 
then describe how architecture specifications are build up 
from component and connector specifications and give an 
overview of insights gained from a case study used to vali- 
date the method. 

1 Introduction 

Existing formal models of software architecture are mainly 
concerned with formalizing specific architectural styles such 
as pipe-filter and client-server [1, 8, 12]. While architectural 
styles abstract away some implementation details, each still 
represents a highly reduced subset of the space of possible 
system designs. The reduction of the design space is what 
makes a style usable by human designers. However, the 
fact that the space is reduced indicates that the choice of 
an architectural style is an important design decision that 
should not be made prior to initial requirements specifica- 
tion. The alternatives for decomposing the system require- 
ments should drive the selection of a specific architectural 
style. 

In previous work, we described the role of declarative 
architecture specifications in system design [11]. Formally, 
an architecture specification is a parameterized specification 
where the parameters correspond to ’sockets’ where compo- 
nents can be ’plugged-in’ to the architecture. An architec- 
ture specification contains axioms that specify constraints 


on the component and system specifications. They may 
specify component behavior that is necessary to guarantee 
correct system-level behavior or define how variation in com- 
ponent behavior affects the behavior of the system. Addi- 
tionally, you can state assumptions that the component can 
make about the environment provided by the architecture. 

The system decomposition described by an architecture 
specification is implemented via an architecture schema writ- 
ten in a target programming language or architecture de- 
scription language. The correctness of the implemented sys- 
tem requires that the constraints placed on the system by 
the specification axioms axe guaranteed by the architecture 
schema. This can be verified based on a semantics of the 
target language [7, 11]. The key point is that verification of 
basic architectural properties is separated from the verifica- 
tion of specific system instantiations. 

2 Compositional Architecture Specifications 

A limitation of our previous work was that the specification 
of architecture constraints was monolithic. We have been in- 
vestigating approaches to construct these architecture spec- 
ifications from parts. One benefit of using a theory-based 
specification notation is that large specifications can be built 
up from smaller specifications using extension and param- 
eterization [4, 6]. Therefore, we define theories for various 
kinds of connectors and bindings and they can be combined, 
extended and instantiated to create an architecture specifi- 
cation. 

2.1 Component Specifications 

We currently use a simple pre/post condition model of com- 
ponents. We are exploring more complex component (and 
connector) models to allow the approach to better support 
concurrency. However, the method of structuring specifica- 
tions is independent of the component model. Therefore, 
the pre/post specifications are sufficient to explore the com- 
positional specification approach. 


2.2 Connector Specifications 

A connection associates an output port of one component 
with an input port of another component. In general, the 
goal is to specify that the combined behavior of two compo- 
nents is always defined, i.e., every valid output at the source 
is a legal input at the destination. The specifics of this re- 
lationship depend upon the way that the components are 
connected. 

For example, a Data Flow connector relates the output of 
one component directly to the input of another component. 
The verification condition for this type of connection is: 

Vx,u> Ia(x) A Oa(x,w) =4' Ib(w) 

If this condition is true, then given a legal input to .4, all 
valid outputs of A are legal inputs to B. We use this condi- 
tion to create a generic data flow connection specification. 
The specification is parameterized on the interface specifi- 
cations of the two components being connected. Specifica- 
tion have also been constructed for buffered, conditional and 
feedback connectors [9]. 

2.3 Interface Binding 

To view a collection of interconnected components as an 
architecture, it must be associated with a single system in- 
terface. This is done by binding the inputs and outputs of 
the system interface with inputs and outputs of the subcom- 
ponent interfaces. There are several types of bindings that 
can be specified and used in an architecture specification. 
For example, the axiom: 

Vx Isystem{x) => Icomponent{x) 

specifies the correctness requirement when all of the system 
inputs are connected to all of the inputs of a single compo- 
nent. This specification is parameterized on the precondi- 
tion of the system and the precondition of the component. 

2.4 Architecture Specification 

Architecture specifications are construct ed by combining and 
extending component, connector and binding specifications. 
For example, Figure 1 shows a block diagram of an architec- 
ture for the Find problem. This architecture is represented 
by the specification diagram [6] in Figure 2. There are input 
bindings between a component specification and the prob- 
lem specification for each of the input variables. The two 
components are connected by a data flow connector from 
the output of the first component to an input variable of 
the second component. The soundness axiom states the 
condition that must be true for the component behavior to 
properly implement the system level behavior. In this case, 
the soundness axiom has the form: 

/({a, k) ) A Oa (a, c)A0fl((c,fe),:))4 0((a,fc>,z) 
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Figure I: Example Find Architecture 


where I and O are the system level specification and Oa 
and Ob are the postconditions of the two components. The 
generic problem and component specifications, together with 
the soundness axiom, represent the generic architecture the- 
ory, labeled Partial Sequential in the diagram. By plug- 
ging in the Find problem specification and the Sort and 
BinSearch component specifications, the specialized Find 
Architecture is created. 


3 Case Study: KWIC 

The Keyword In Context (KWIC) indexing system has been 
used as an example to present software architecture con- 
cepts. Shaw and Garlan’s book [12] contains four solutions 
to the problem that have different architectures. The differ- 
ent architectures represent various combinations of choices 
regarding the tradeoffs on issues such as reusability, adapt- 
ability, performance. The goal of this case study was not 
to define a new architecture for KWIC, but to describe the 
existing KWIC architectures using compositional specifica- 
tions. Details of the case study can be found elsewhere [9]. 

Traditionally, the KWIC problem is solved using the fol- 
lowing four components: Input, Circular Shift, Alphabetize, 
and Output [12]. Our approach to specifying the KWIC ar- 
chitectures is to specify the interface and behavior of these 
four components, and then integrate them into the different 
architectures. The integration is non-trivial because, in the 
different architectures, the components have slightly differ- 
ent interfaces. We attempted to separate the specification 
of the core component functionality from the specification 
of component interaction. Then the core components were 
integrated using wrappers (specified as one-component ar- 
chitectures). The different interaction styles were captured 
by the connector constraints. 

For example, a specification diagram for the KWIC data 
flow architecture is shown in Figure 3. The sub-diagram 
in the lower left shows how an incremental shift component 
is wrapped to create a Shift component with the correct 
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Figure 2: Specification Diagram for Find Architecture 



Figure 3: Specification Diagram for KWIC Data Flow Architecture 



interface. 

The second architecture we described was the reactive ar- 
chitecture, where components do not wait for the previous 
component to finish processing, but operate incrementally. 
For this example, it was necessary to specify an incremental 
version of the Alphabetize component. The original Alpha- 
betize component could be built using an incremental ver- 
sion and a wrapper. However, this unnecessarily limits the 
sorting algorithm to insertion sort, pointing out a tradeoff 
between the data flow and reactive architectures: the per- 
formance gained by the concurrent execution of components 
in the reactive style results in a potential performance loss 
as a result of limiting the sorting algorithm. 

This experience also pointed out the importance of wrap- 
pers in component integration. We believe that it may be 
useful to consider wrappers as first class entities in an archi- 
tecture description language. 

4 Related Work 

This approach to architecture modeling arose out of an ef- 
fort to model component adaptation tactics within the RE- 
BOUND framework [9, 10]. The architecture specification 
method (in it’s monolithic form) was tested on the architec- 
ture of an Al-based control system for a deep-space probe [11]. 

Most efforts to formalize software architecture are tar- 
geted at formalizing styles and not with the problem decom- 
position aspects of architecture. Two approaches use alge- 
braic theories to specify axchitectures. Marconi et. al. [8] 
use theory-based architecture representations to support ar- 
chitecture refinement. This work is concerned with architec- 
ture implementation and could be used to specify links be- 
tween architecture specifications and architecture schemas. 
Gerken [5] also uses theories as the main unit of specifi- 
cation. We believe that the process logic descriptions of 
architectures are too operational to effectively model the re- 
lationships we are interested in. 

5 Future Work 

We are currently experimenting with a more general compo- 
nent model that will provide better support for concurrency 
and event-based communication. We are attempting to bal- 
ance the expressibility of languages like Wright [2] (based on 
CSP) with the need to model requirements without imple- 
mentation bias. We are also interested in mapping compo- 
nent and connector implementations onto commercial com- 
ponent platforms, such as JAVA beans. This could provide 
a reliable method for NASA to use COTS components in 
critical systems, by formally verifying a reference architec- 
ture for flight-critical applications built on top of a reliable 
platform. 
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